[iOS] MVCからクリーンアーキテクチャまで。書籍「iOSアプリ設計パターン入門」が良かったのでご紹介

こんにちは。きんくまです。

現在担当している案件でクリーンアーキテクチャが採用されていたので、勉強しています。
そこで読んでいる本を２冊ご紹介します。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

まずはクリーンアーキテクチャを提唱したRobert C. Martinさん（アンクル・ボブ）の本。

クリーンアーキテクチャがタイトルになっているのですが、それは本の中の一部分です。
実際にはこんなことが書いてあります。

1. イントロダクション（設計とは何か）
2. プログラミングパラダイムについて（構造化プログラミング、オブジェクト指向プログラミング、関数型プログラミング）
3. SOLID原則（オープン・クローズドの原則など）
4. コンポーネントの原則
5. アーキテクチャ（アーキテクチャとは？、境界、ビジネスルール、クリーンアーキテクチャ）
6. 詳細

これまでのプログラミングの流れだったり、疎結合にするために境界を超えるときにinterfaceを利用して必要以上の情報を与えないなど、設計に関することがまとめられています。

ただ実際に読んでみると、書いてあるコードが部分的だったりして、しっかり理解できているのか、いまいちわからないところもありました。ふわっとした理解といいますか。

といいつつ、こういう本は手元に置いておいて、何度か読むことで考え方が馴染んでくるのだと思います。

次に今回の目的であったクリーンアーキテクチャについて、実装のコードも書いてある次の本をご紹介します。

iOSアプリ設計パターン入門

PEAKS（ピークス）｜iOSアプリ設計パターン入門

もともとは技術書クラウドファンディングだそうです。執筆されるかどうかは、申し込み者の人数によっていました。それで無事プロジェクトも成立して、執筆されました。

ですが私が欲しいと思ったときは、少し遅かったため、残念ながら最初のクラウドファンディング申し込み時の人だけが購入できて、一般向けはまだされていませんでした。（当然なのですが）

ところが最近一般向けに購入ができるようになり、私も入手できました。（支払いはAmazon Payというやつで、Amazonアカウントがあればすぐに買えました）

本の内容

===
第1部　設計を知る
===

第1章　設計するということ 
第2章　設計にパターンを適用する前に
第3章　Swiftらしく設計する
第4章　アーキテクチャのパターンを鳥瞰する

===
第2部　iOSアプリのための設計パターン
===

第5章　MVC
第6章　MVP
第7章　MVVM
第8章　Flux
第9章　Redux
第10章　Clean Architecture
第11章　アプリの起動経路 - Application Coordinatorの導入
第12章　画面遷移のパターン - Routerの導入
第13章　第2部まとめ - アーキテクチャの選定基準

===
第3部　設計をサービスに導入する
===

第14章　Fluxの導入例
第15章　Reduxの導入例 - 大規模アプリケーションにReduxを導入する

どうでしょう？Webのフロントエンドを知っている方なら、あーなるほど！となるのではないでしょうか。

MVPやMVVMなどのGUIアーキテクチャについても、歴史的な経緯なども含めて丁寧に解説してくれています。このあたりのことについて、なんとなくは知っていたけど、ちゃんとはわかっていなかったので、とても勉強になりました。

この本でとても良いなと思った点は、なるべく客観的にそれぞれのパターンについてメリット・デメリットを分析しているところです。絶対にうまくいくパターンというものはなく、案件の規模やかかわるスタッフに合うのか合わないのか？ここが大事なポイントです。その検討材料として、とても良いと思いました。

当初の目的であったクリーンアーキテクチャについて。
アンクル・ボブ本では、ふわっとした理解だったのですが、protocolを使い、境界を超えてそれぞれの層（レイヤー）をつなぐ流れがだいぶ理解できました。（iOSのswiftではinterfaceはなくprotocolを使う）

アーキテクチャの導入について

先月、弊社に入社したのですが、それまではフリーランスとして一人で開発することがほとんどでした。そのため、俺俺アーキテクチャだとしても特に問題はありませんでした。

俺俺アーキテクチャ自体は、一人で開発する分には特に問題がないと思います。自分で考えた方針があり、何をどこに書くかがわかっているからです。

ただ、その案件を他の人に引き継いだり、また別の人の俺俺アーキテクチャを引き継ぐときに、もし説明が複雑なものになってしまう場合は、注意が必要だと思います。

そんなときに、広く広まっているアーキテクチャを採用することで、その引き継ぎがスムーズにできると思います。アーキテクチャごとの考え方があり、そのパターンの場合は、どこに何を書くかの方針が決まっているからです。そのため新しく入った人にも、書かれているコードの意図が読み取りやすく、新規のコードも書きやすいものになると思います。

ただし、俺俺アーキテクチャ自体を全否定する必要もないと思います。もし案件にそのアーキテクチャが合っていれば良いし、時間がないときなどは新しいものを試すよりも慣れているもので書いてしまった方が速いからです。

また、次々と出てくる新しいアーキテクチャたちも最初は俺俺アーキテクチャでした。それに名前がついて、色んな人の支持が集まり、広まることで有名なアーキテクチャとして採用されていったという経緯があります。（自分の俺俺アーキテクチャが広まるとも思えませんが、、、）

ただ、広く広まるからには、何か理由があるはずです。その理由を学習して、良いものは取り込む姿勢を常に持っておく方が自身の成長にもつながるかなーと思いました。（結果的にやらないとしても「知らないから使えない」のではなく、「知っているけど使わない」という方が健全かなーと）

というわけで、本のご紹介でしたー。ではでは。